NMIを利用したNITRO世代EC2の強制再起動とメモリダンプ生成を試してみた
AWSチームのすずきです。
NITRO世代のEC2インスタンスで稼働中のOSに対し、ハードウェアNMI(マスク不可割り込み)を発生させて、OSの強制再起動が可能になりました。
今回AWSCLIを利用して、EC2上で動作中の Windows OSの強制再起動とメモリダンプの生成動作を確認する機会がありましたので、紹介させて頂きます。
設定
Windows_Server-2016 のAMIを利用してEC2を起動、メモリダンプの設定を行いました。
AMI
- Windows_Server-2016-Japanese-Full-Base-2019.07.12 - ami-0bc8442658e36a4d2
インスタンスタイプ
- t3.micro
NITRO世代「T3」のインスタンスを利用しました。
2019年8月時点、C5, C5d, C5n, i3.metal, I3en, M5, M5a, M5ad, M5d, p3dn.24xlarge, R5, R5a, R5ad, R5d, T3, T3a, Z1d のインスタンスが「SendDiagnosticInterrupt」を利用可能なインスタンスとなります。
メモリダンプ設定
コントロールパネル > システムとセキュリティ > システム より、「システムの詳細設定」を開きます。
「詳細設定」より、「起動と回復の設定」を開きます
システムエラーの設定で、デバッグ情報の書き込みを選択します。
今回、「自動メモリダンプ」と「完全メモリダンプ」を試しました。
参考
API操作
2019年8月時点で最新の 1.16.220 のAWS CLIをインストールした Amazon Linux 2環境を利用しました。
AMI
- amzn2-ami-hvm-2.0.20190618-x86_64-gp2 (ami-0c3fd0f5d33134a76)
AWS CLI
- aws-cli/1.16.220 Python/3.7.4 Linux/4.14.123-111.109.amzn2.x86_64 botocore/1.12.210
sudo yum install python3 -y sudo pip3 install awscli --upgrade /usr/loval/bin/aws --version aws-cli/1.16.220 Python/3.7.4 Linux/4.14.123-111.109.amzn2.x86_64 botocore/1.12.210
https://dev.classmethod.jp/cloud/aws/latest-version-awscli-al2/
IAM
今回は「ec2:*」の権限をもつ「AmazonEC2FullAccess」の管理ポリシーをEC2ロールとして付与して利用しました。
強制再起動が望ましくないインスタンスが同一AWSアカウントに存在する場合、対象リソースを絞った設定とする事をおすすめします。
実行
dry-run
「SendDiagnosticInterrupt」が可能なインスタンスである事を確認します。
$ aws ec2 send-diagnostic-interrupt --instance-id i-xxxxxxxxxxxxxxxxx --dry-run An error occurred (DryRunOperation) when calling the SendDiagnosticInterrupt operation: Request would have succeeded, but DryRun flag is set.
no-dry-run
「--no-dry-run」、または「dry-run」オプションを省略した場合、CLIは戻り値を返さず強制再起動が行われます。
$ aws ec2 send-diagnostic-interrupt --instance-id i-xxxxxxxxxxxxxxxxx --no-dry-run
確認
デフォルトでは「C:\Windows\MEMORY.DMP」のファイル名でダンプファイルが生成されます。
ダンプファイルの容量は、「t3.micro」の検証環境では自動メモリダンプは「278MB」、完全メモリダンプでは搭載メモリと同等の「995MB」でした。
- 自動メモリダンプ
- 完全メモリダンプ、
完全ダンプを出力する場合、搭載メモリ相当のダンプファイルが生成される事になります。 多くのメモリを搭載するEC2インスタンスで完全ダンプを取得する場合、出力先のEBSの拡張や「M5d」などインスタンスストアの利用と、 可能であれば本番と同等スペックの検証環境を準備した上で、メモリダンプ生成に伴う所要時間の確認まで実施する事をおすすめします。
まとめ
RDP、SSH、SSMなどのリモート操作も受け付けなくなったEC2インスタンスに対し、強制再起動を行う手段が増えました。
応答しなくなったEC2の再起動を 「StopInstances / StartInstances」、「RebootInstances」 で行う際、OS停止に強制停止(force)オプションを必須とする事がありましたが、 「SendDiagnosticInterrupt」により、OSがNMI割り込みに反応できる状態であれば高速な再起動が実現できる可能性があります。
また、強制再起動時に生成できたメモリダンプを保守サポートベンダに提供する事で障害解析に役立つ場合もあります。 今回は Windows OSの動作について紹介させて頂きましたが、Amazon Linux 2、RHEL、Ubuntu など Linux OS環境での設定と動作についても、改めて紹介させて頂きたいと思います。
